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A NEW LOOK, A NEW ATTITUDE 

Hello and welcome to our new developer’s newsletter: 
THE ATARI FORUM. The new look reflects a fresh and 
positive attitude within the Atari software group: we want 
to help you, the software developer, produce higher quali- 
ty software that is competitive in the marketplace. The 
newsletter will be published every two months. It is your 
newsletter; so please do not hesitate to comment on its 
content, or to submit articles that would be of benefit to 
other developers. 

Along with our new look, we have new goals: 

1. We want to improve the dialog between, you the soft- 
ware developer, and Atari-this does not mean that the 
communication will be one-way: we want to establish a 
two-way link so that we can mutually benefit from our 
relationship. Therefore, if there is something you wish 
to convey that is not right, we are interested in making 
it right. 

2. We want to improve our support program-from a 
technical, sales, and marketing point of view. Since I will 
be interacting with sales and marketing, keeping me 
informed will ensure that your product(s) are known to 
the Atari organization-please forward any product 
information-and samples-to my attention. The samples 
are necessary because it physically confirms the 
product’s existence and allows us to conduct a first- 
hand evaluation. 

I am not completely new to the Atari scene, many 
of you who have dealt with me know that I am respon- 
sive and thorough with my commitments. I have a good 
understanding of the marketplace as a whole, please 
don’t hesitate to contact me for input and support. 


“...We want to establish a two-way link, so 
that we can mutually benefit from our 
relationships. ” 


3. Another of our primary objectives is to establish applica- 
tion software guidelines. Specifically, I want to focus 
on the user interface: that part of the software which 
the user can perceive. In the next issue of this news- 
letter, I plan to publish a comprehensive set of guide- 


lines; if you have any suggestions, please contact me at 
(408) 745-2010. Also in the works is a developer’s confer- 
ence. Full details of the conference will appear in our next 
issue. 

I want 1988 to be our best year for the Atari ST; by 
supporting each other, I see no reason why this can’t be 
achieved. 

Joe Ferrari: Editor 


Atari’s New CD ROM Player 

Atari Corporation is pleased to announce its new low- 
cost (under $600) CD ROM player for use with the ST line 
of computers; it is capable of reading both data and audio 
CDs, and connects directly to the ST’s high-speed DMA 
bus. 

The ST is currently one of the best-selling computers 
in Europe-our goal is to bring that success to the USA. 
The ST, with its high resolution display, user-friendly 
interface, and the massive data storage of a CD ROM 
player, becomes an ideal, low-cost workstation. 

But that is only one part of our strategy: The CD ROM 
player’s ability to output audio provides the software 
developer an enormous potential in the educational field. 
One of the major weaknesses of existing educational soft- 
ware has been its inability to provide sufficient audio 
response as part of the machine/user interaction: Atari’s 
new CD ROM player will provide software developers with 
a new tool for teaching--the possibilities are infinite! 

In the entertainment sector, the CD ROM’s ability to 
output audio in stereo will bring a new dimension to video 
games. It isn’t difficult to see some explosive growth in 
this segment of the market, (continued on page 4) 


What’s Inside 


1. ABAQ Page 2 

2. Atari on GEnie Page 2 

3. Questions and Answers Page 3 


(The Atari Forum was created— in its entirety— using an Atari Publishing System MEGA 4, SLM804, Atari Deskset, Easy Draw) 



Page 2 


Atari Support on GEnie 

Last year, Atari began providing online support to our 
developers. This has proven to be a successful way for Atari 
staffers and our developers to exchange information. 

Since that time, a new service has appeared, providing 
online support at reduced rates. GEnie, a service of General 
Electric, has developed into a leading provider of personal 
computer support. In fact, the Atari support areas on 
GEnie are probably larger now than the support areas on 
CompuServe. 

As a result, Atari has opened a new area, for developers 
only, on GEnie. This is in addition to the area on 
CompuServe. 

On GEnie you will pay only $5 per hour for connect 
charges at 300 or 1200 baud, which is less than half the 
CompuServe 1200 baud rate. And GEnie downloads are 
usually about twice the speed of those on CompuServe, 
since the GEnie host sends the download file to the local 
GEnie node before it gets to you, effectively eliminating 
network delays in Xmodem handshaking. 

GEnie is making a special offer available to Atari 
developers. You can sign up for GEnie service at no cost- 
GEnie is waiving the usual $18 signup fee. To sign up for 
GEnie, follow this procedure: 

Set your computer’s terminal program to HALF 
DUPLEX.Using your modem, dial 1-800-638-8369. 

Upon connection, type HHH (and don’t hit RETURN). 
After a couple of seconds, GEnie will send you the 
promptU#=. 

Type this: XJM 11 887, Atari and hit RETURN. 

Now GEnie will walk you through the rest of the 
procedure, taking your name, address, billing info, etc. 
When you finish, you will get a user ID and a password, 
and you’ll be able to call your local GEnie number 
immediately. 

Once online on GEnie, at any menu prompt type M565 
to get to the Atari developers roundtable. At that time 
you’ll receive instructions telling you how to get approv- 
ed to enter this private area. 

You can also type Atari at a menu prompt to get to 
the list of all Atari support areas on GEnie. There is a huge 
ST area there, with more than 4000 files to download and 
message sections on all kinds of products. Weekly realtime 
conferences in the ST roundtable, open to the public, are 
held each Wednesday at 10:00 PM Eastern time. If you are 
interested in speaking in a formal conference to discuss 
your product or any subject that interests you, let us know 
by email to the ATARI address. 

If you are used to CompuServe, you’ll find GEnie to 
be a bit different. It will take a little getting used to. Feel 
free to send electronic mail on GEnie to the Atari address 
to get help from us in learning your way around. 

We’ll see you online! 

Neil Harris 


ABAQ: A High-Performance Workstation 

At Fall Comdex ’87, Atari announced a new addition 
to its growing computer product line: ABAQ. The new com- 
puter is based on the revolutionary transputer chip. ABAQ 
is the first parallel processing, high-performance, personal 
workstation of its kind. 

With ABAQ, advances in applications such as desktop 
publishing and CAD will be phenomenal. Full page displays 
will move desktop publishing into another realm. The sohd 
and wire frame modeling graphics capabilities will bring 
3-D CAD, rendering and rotation, up to levels that 
previously desktop computers could not have performed. 
The better than broadcast quality resolution will allow near- 
ly photographic quality graphics. This feature alone will 
have a tremendous impact on film, television and video in- 
dustries ability to computer generate special effects. 

The screen resolutions available for ABAQ are very 
important. All screen resolutions are 60HZ, portrait 
quality. The highest mode is 1280 x 960 (4 bit/pixel) gray 
scale. This resolution is excellent for engineering drawings, 
desktop publishing, film, and television or video special ef- 
fects work. The second resolution is 1024 x 786 (8 bit/pixel) 
color. This resolution will be beneficial in any CAD, color 
picture or graphic work. The 640 x 480 (8 bits/pixel/2 screen) 
resolution is perfect for animation work. The lowest resolu- 
tion is 512 x 480 (32 bit/pixel 24 bit/true color plus overlay 
& tag bits). This resolution may be utilized for finely shad- 
ed pictures. 

Additional ABAQ advantages include the ability to 
create a processor farm of upwards of 1000 processors, 
SCSI drive support, and a floating point processor built 
into the transputer chip. 

The built-in floating point processor in itself is a great 
advantage. ABAQ offers calculating speeds a single pro- 
cessor workstation can’t. The effect of these calculating 
speeds on any number of applications will be enormous. 

ABAQ provides for the addition of up to three inter- 
nal expansion cards. These cards may include up to 64 
megabytes of addressable DRAM, or different graphics 
cards for specialty applications. The three add-on caids may 
be configured as 12+ 1 transputers which would provide 
130 MIPS or about 20Mflops in a desktop package. The 
full bus and appropriate links are available. It also pro- 
vides connections to parallel processor farms and links to 
fast peripherals such as a laser printer, disc server, etc. 

The ABAQ operating system is HELIOS. A multi- 
processor, multi-user system, sympathetic to transputer 
architecture- and familiar to Unix users. The user interfaces 
include X-Windows 'V»rs. 11) and GEM-VDI driver. Abaq 
works with the Atari MEGA Computer. 

ABAQ utilizes a high performance transputer 
microprocessor with a reduced instruction set, capable of 
delivering computer power in excess of ten times a PC/AT. 
It is the most powerful single chip computer in the world. 

Although the ABAQ transputer chip has a reduced in- 
struction set, it goes beyond the traditional RISC (Reduced 
Instruction Set Computer). The ABAQ transputer chip con- 
sists of a small core instruction set surrounded by collec- 
tions of application specific instructions. Perhaps its key 
feature is the ability of the transputer to allow 100 or more 
transputers to connect together to provide a low-cost 
desktop computer with the power of a supercomputer. 



With the advent of powerful 32-bit microprocessors, 
and advances in graphics hardware, a new generation of 
affordable powerful personal workstations has become 
possible. The systems will, it is predicted, provide an or- 
der of magnitude better price/performance than any per- 
sonal computer currently being sold. 

Using the transputer as the heart of ABAQ not only 
allows the production of a cost-effective advanced personal 
workstation, it also provides the ability to plug in more 
ower as needed. Such systems set new standards in 
computing, providing solutions that previously required ex- 
pensive mainframes, all on one desk. 


Questions & Answers 

Here are the latest questions from the Atari developers mailbag as 
answered by John Feagans. Leave questions on CompuServe for 
PIN 70007,1072 or GO PCS5 7 for Atari developer SIG information. 

1. Corrections 

Let us try this one more time... In the last question and 
answer we tried to show a correct solution to a problem. 
The Abacus software book, “Atari ST Graphics and 
Sound”, has a typographical error on page 54. There is a 
C example and a Pascal example of open virtual 
workstation. The problem with the C example is that this 
Abacus book does not initialize the int_in array as zero- 
based. The for loop starts at 1. The problem with our fix 
is that my fingers were out to lunch when I typed in the 
example. The correct subroutine should be as follows: 

open_vwork() 

{ 

int i; 

for (i = 1; -<10; i++) 
int_jn[i] = 1 ; 
int_in[10] = 1; 

int in[0] — Getrezf) + 2; 

v_opnwk(int_in, &handle, int_out); 

} 

2. DOS 

Q: I thought that TOS could only detect a floppy disk media 
change by reading the boot sector and checking the 
serial number. But if you use a command shell 
(COMMAND.TOS will do) and type “Is” on disk A: once, 
then wait for as much time as you want without ex- 
ecuting any other commands, then type “Is” again, the 
directory comes up WITHOUT accessing the disk. Pop 
the disk and put it back in. The next “Is” will make the 
OS access the disk. Apparently, there IS some sort of 
hardware mechanism for detecting a media change. Does 
anyone know how this can be accessed on a hardware 
level? 

A: The OS twitches the drive select line once every VBI, 
then reads the write protect line to detect a media 
change. This procedure does not work with write pro- 
tected disks. Adding non-Atari drives to the ST makes 
disk change sensing fail as well. 

3. AES 

Q: I am looking for information concerning the creation of 
accessories in assembler. According to ABACUS, to 
create an application, you must calculate the program 
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size, and do a setblock call to return leftover memory. 

Is this necessary when you create an accessory? If not, 
what should it be replaced with? 

A: When the desktop goes to the accessories initialization 
code, memory has already been shrunk to fit. You still 
have to malloc buffers and allocate your stack. That is 
why we provide two start modules in the Atari 
developers kit. 

Q: My company is considering developing a 16 bit sampler 
(audio) for the ST along with support software. I was 
wondering if you might be able to help me out with some 
questions I have concerning the connection of any hard- 
ware we might develop to the ST. 

1) Is there any particular advantage to using the car- 
tridge slot over the DMA port? 

2) Will either or both of these ports be available on the 
Mega ST and future ST’s? 

3) Is the ROM expansion slot strictly Read Only? I 
seem to recall that some cartridge products that I’ve 
heard of, both read and write to the port. 

4) Are there any problems with daisy chaining devices 
to the DMA port? The hard drive doesn’t seem to have 
any facility for daisy chaining. Actually, I’m relatively 
inexperienced at hardware level programming so I’d ap- 
preciate any help or sample code that shows how to poll 
for bytes at the DMA port or code an interupt handler 
for it. 

5) We’re going to need a fast dock for sampling (at least 
44 Khz). I was planning on looking at Timer A of the 
68901 for this. Will this work or am I barking up the 
wrong tree? Do you have or know of any sample code 
showing how to obtain a timer of this nature? 

I must apologize for the length of this note and the bar- 
rage of questions herein but I’d appreciate any help you 
can give me to get me started looking in the right 
direction(s). Thanks in advance. 

A: The ROM cartridge port and the DMA are present in 
all current and in future mega-STs. I recommend using 
the DMA port because people making cartridges do not 
provide for any stacking. The cartridge port is read only, 
but there are ways to write data by using the address 
lines. Current hard drives do not have any daisy chain- 
ing capability but new production drives have two 
connectors. All hard drives have an addressable unit 
number. Timer-A is reserved for use by applications. 

Statement: Yes! I agree, John, enough memory must be lef- 
tover for darling GEM niceties. TOS is not very friend- 
ly when it doesn’t have enough memory. I had a program 
give me an address error (vector 3) from WITHIN the 
roms. I eventually (after two days) tracked it down to 

a vs clip I was using after a fsel input. Huh? That 

really threw me because that’s a *real* basic operation. 
However, I had inadvertently let another zero creep into 
my MallocO and was stealing lots more memory than I 
needed. Rather than pass me errors, GEM decided to 
bomb. Oh well, live and learn. 

A: You should never, on any system, be it ST or another, 
MallocO memory 1 ’ithout first doing a Malloc(-l) to see 
how much is available. You also must leave memory for 
resource files that you may request the system to load 
and also the file selector. The precise amount of memory 
that the file selector input requires is $a00 (2560) bytes. 
You should also leave memory for any program that 
yours may Pexec(). 
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Q: I have trouble with event library calls after I have done 
anything with the VDI calls to determine mouse posi- 
tion and button state. It seems like the event library 
never sees the button come up and thinks it is still down. 
You have to click again to get the correct state. 

A: We do not recommend using vq mouse if you are plan- 

ning on doing any event library calls such as 

event multi. What is happening is just as you have 

described-the vq mouse is siphoning off some button 

states which are never passed on to GEM. The AES only 
knows about the last state it had such as that the but- 
ton was down. There are two acceptable ways around 
this. First, you can do the exchange mouse or button 
vector calls in the VDI and insert your own handler 
which will scan the mouse position and button states 
and deposit this information in your own variables 
before passing on to the previous handler. Second, you 
can query the line-A variables for button state and 
mouse position which can be acessed by the following 
example: 

long linea vars; 

int *gcurx,*gcury; 
char *gbutton; 

/* initialization code *1 
linea_init(); 

/* code to use mouse data *1 

gcurx = linea vars-602; 

gcury= linea vars-600; 

gbutton=linea vars-348; 

;68000 assembler to do line-A init 
linea init: 

movem.1 d0-d2/a0-a2,-(sp) 
dc.w SAOOO 

moved aO,__linea vars 

movem.1 (sp)+,d0-d2/a0-a2 
rts 

Q: I’ve got a couple of editable fields on a dialog box, I’ve 
go an I-BOX definedas exit default, to be able to han- 
dle the return key my self, that is: when theuser edits 
the first field and presses return the application is 
supossed to: 

1 read the 1st field input. 

2 fill the 2nd field with some feedback. 

3 let the user modify it. 

I can handle most of it, the main problem is to know 
in wich field is the user when he presses the return key, 
because I’ve got to do some other stuff when the ’Ret’ 
is pressed on the 2nd field. Any ideas?? 

A: You need to go through the object list and see which 
object state is selected. That’s is how you tell. 

Q: I wanted to detect a double click NOT in a form do 

but after receiving a mouse button event from an 
event__Multi call. I can detect a single click and wait 
by using a timer/button event. This way if a button down 
event occurs it would be the second click in the double 


click, otherwise it would be a single click or a mouse 
drag. The problem is that the delay causes an 
undesirable interuption in the mouse operations when 
there is only o one click. The wait for a second click 
causes a delay when only one click is pressed. Any 
solutions!!! Please!!! 

A: This answer appeared in ATARI DEV on CompuServe 
from Corey Cole. See his program Button.c in DLO for 
more information. “I handle double-clicks by requesting 

single-click through the evnt multi, and keeping track 

of state transitions myself. This also allows reasonably 
clean handling of the right mouse button. This approach 
is a little strange in feel to users accustomed to having 
to double-click very quickly, however - the second click 
might be missed if too fast. (On the other hand, I don’t 
have a time limit for multiple clicks in one place, 
something I prefer to the GEM approach.)” 

Q: Does the Alcyon C support floating point? 

A: Yes. The one shipped in the developers kit supports 
single precision with the Motorola fast floating point 
routines and IEEE single and double precision is 
available in the optional 4.14 upgrade. 

4. New On CompuServe 

In data library 7 (for registered Atari Developers only) in 
the Atari Developers SIG on CompuServe, the following 
files are new this month: 

madmac.arc 

A fast macro assembler, also generates .prg files directly 
from modules without requiring linking and or relmod. 

aln.arc 

A fast linker, use as a replacement for link68. 

Atari’s CD ROM (continued from page 1) 

A CD extended BIOS is being developed to provide ST 
applications with a standard interface to the CD ROM 
player command set. In the future, Compact Disk 
Operating Systems will become available for emerging CD 
ROM standards (such as High Sierra Group format). 

Join us in supporting this revolutionary product. The 
Atari CD ROM player will be available for software 
development in February of 1988. Product release is 
scheduled for the first quarter of 1988. We are interested 
in working with your company to provide a variety of CD 
ROM applications-and also to insure compatibility of our 
products with yours. 

We also look forward to exploring possibilities in the 
MS-DOS world with our line of PC-Compatibles. For more 
developer information about the Atari CD ROM player, 
write to us at our Sunnyvale address, Attn: CD ROM Dept. 
Please send complete information on your company and its 
products as well. This will be a great help in our efforts to 
understand and support the CD ROM community. 

Mike Schmal 

Director of CD ROM Technology 




